I am on M1 (Xcode Version 15.4 (15F31d), MacOS 14.5 (23F79), Simulator IOS 17.4) and as far as I remember printing common usage register was possible. I am not sure why it stopped to work rid, rsi and etc (arg1 arg2 seems like still working).

if we define a property in the following way: @property (atomic) NSString *latestObject; Can we assume that the read write to that value is thread safe? i.e the value will be correct. Or it is better to write our own setter/getter with Locks?

Attaching several crash traces: 2024-02-29_22-48-33.6864_-0600-3f948243e21b4c68d77a38d9cf1cecfdfe2c1565.crash 2024-03-04_15-00-02.9335_-0600-75000cd5acd63ba1434f2ffb3648b97259dddb88.crash 2024-03-05_08-55-47.2097_-0500-f682b25663107ad46f091d65f402f2be31f3f3c6.crash 2024-03-11_08-09-00.4057_-0400-e37d1a635d51afbb67ac38b42dd79c1718a408e8.crash 2024-03-15_16-20-22.6446_-0600-d4ebccf455e8305038ca564a39a5661a1dce6231.crash The final code: - (NSObject*)objectAtIndex:(NSUInteger)index { if (index < self.count) { return [self.embeddedArray objectAtIndex:index]; } else { [PNDErrorReporting reportError:PNDErrorReasonTypeSafeCollectionCrashPrevented message:@"Error msg"]; return nil; } } We subclass NSMutableArray to prevent potential crashes. but we encounter a new crash in our sdk for one of the clients. Also we noticed the stack trace skipped one of the frames (stack calls) in the crash report, in which cases the stack trace wont be identical to the actual code (beside inline)?

It seems that that all the crashes are coming from the same place BUT the error is slightly different. Attaching the code that responsible for the crash: static NSString * const kDelimiter = @"#$@"; + (PNDArray *)getObjectsFromData:(NSData *)data { NSString *dataStr = [[NSString alloc] initWithData:data encoding:encoding]; dataStr = [dataStr stringByReplacingOccurrencesOfString:@"\\u0000" withString:@""]; NSArray *components = [dataStr componentsSeparatedByString:kDelimiter]; NSMutableArray *result = [NSMutableArray array]; for (NSString *jsonStr in components) { if (jsonStr != nil && jsonStr.length != 0 && ![jsonStr hasPrefix:kBatchUUID]) { [result addObject:jsonStr]; } } return [PNDArray arrayWithArray:result]; } 2024-04-16_17-15-34.1922_-0600-dfa2faecf702f23e3f6558bea986de4f62851761.crash 2024-04-24_04-56-53.4664_-0500-6b125d3d03b7e497b6be339c2abb52f29658824b.crash 2024-04-25_11-13-53.1326_-0700-bfe370be3eae8d65f465eac714905dd3d13aa665.crash 2024-05-03_11-47-36.6085_-0500-2793587e7ed1c02b0e4334bbc3aa0bd7f7a0cf3d.crash 2024-05-05_10-49-40.5969_-0700-4d86636b0877fceb8c0cdb9586ee16dfb0a9c934.crash

In our third party SDK we would like to use microphone (as optional feature) in case the hosting app allows it. From the docs requestRecordPermission will crash if no NSMicrophoneUsageDescription exists in the hosting app info.plist. Obviously I don't want to crash the app. I would like to check if the hosting app will allow me to call requestRecordPermission before calling it? Is it possible

I have a general question that confusing me. I am on M1 and I can build my app on Xcode (or create an archive) for device. Looking in to derived data I can see Debug-iphones (and simulators) folders, I can get the .app and drag/drop it to the simulator. When trying to run the app the app will crash with error: EXEC 14 Binary with wrong platform I understand that it wasn't build for simulators but rather it was build for devices and there fore the crash, but when thinking about it I dont understand why? (at least theoretically it shouldn't crash as it was build for arm64 ). Inspected the binary with lipo it was build for arm64. Comparing the binaries for simulator and device (with otool) I dont see a lot of difference except the rpath. So how does IOS knows it was build for device and not simulator (wrong platform)? is there a way to add some sort of relaxation (in the end both binaries were build for arm64).

I have the following crash in swiftui that relates to memory reallocation, which I am not sure how to handle Crash.txt

One of our client has contacted us with the following error : Task .&amp;lt;3&amp;gt; request https:URL is NOT allowed to set HSTS for main doc (null) Th request is sent from our SDK. According to the client it happens only on Vision Pro. All our requests to the server on the SDK side are https. The serve has the following header: X-Content-Type-Options X-Frame-Options Strict-Transport-Security Can somebody share some insight?

Lately we have added swift code to our SDK. (especially swiftUI library). The SDK deployment target is ios9. While importing the SDK to the hosting app with the same deployment target and building via Xcode (13.4) everything works fine. When we try to build it via xcodebuild (xcodebuild -workspace UIKitCatalog.xcworkspace -scheme UIKitCatalog -sdk "iphonesimulator") the build is done successfully but the the app is crashing on app lunch (sim and device) . Increasing the deployment target of the hosting app to iOS 13 fixes the issue (unfortunately we cant force our customers to do the same) CrashReporter Key: 74B25560-EFCE-769F-F0B4-E4DD4C6B09A4 Hardware Model: MacBookPro15,1 Process: UIKitCatalog [63980] Path: /Users/USER/Library/Developer/CoreSimulator/Devices/F044CBD3-80D6-49FB-BAC9-FA48FA3CFF7E/data/Containers/Bundle/Application/72290230-2DB3-4F75-8327-75B6E4E9947C/UIKitCatalog.app/UIKitCatalog Identifier: ba.UIKitCatalog Version: 2.0.0.23386 (23386) Code Type: X86-64 (Native) Role: Foreground Parent Process: launchd_sim [56632] Coalition: com.apple.CoreSimulator.SimDevice.F044CBD3-80D6-49FB-BAC9-FA48FA3CFF7E [10638] Responsible Process: SimulatorTrampoline [2048] Date/Time: 2022-08-29 11:59:21.3026 +0300 Launch Time: 2022-08-29 11:59:19.9381 +0300 OS Version: macOS 12.5.1 (21G83) Release Type: User Report Version: 104 Exception Type: EXC_CRASH (SIGABRT) Exception Codes: 0x0000000000000000, 0x0000000000000000 Exception Note: EXC_CORPSE_NOTIFY Triggered by Thread: 0 Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 libsystem_kernel.dylib 0x7fff7017300e __pthread_kill + 10 1 libsystem_pthread.dylib 0x7fff701cb1ff pthread_kill + 263 2 libsystem_c.dylib 0x7fff2010b6b7 abort + 130 3 libswiftCore.dylib 0x10e7c0af5 swift::fatalError(unsigned int, char const*, ...) + 149 4 libswiftCore.dylib 0x10e7b86ec checkVersion() + 44 5 dyld_sim 0x10d0689f7 invocation function for block in dyld4::Loader::findAndRunAllInitializers(dyld4::RuntimeState&) const + 182 6 dyld_sim 0x10d0850f5 invocation function for block in dyld3::MachOAnalyzer::forEachInitializer(Diagnostics&, dyld3::MachOAnalyzer::VMAddrConverter const&, void (unsigned int) block_pointer, void const*) const + 129 7 dyld_sim 0x10d07e58c invocation function for block in dyld3::MachOFile::forEachSection(void (dyld3::MachOFile::SectionInfo const&, bool, bool&) block_pointer) const + 555 8 dyld_sim 0x10d07d6e9 dyld3::MachOFile::forEachLoadCommand(Diagnostics&, void (load_command const*, bool&) block_pointer) const + 129 9 dyld_sim 0x10d07e31f dyld3::MachOFile::forEachSection(void (dyld3::MachOFile::SectionInfo const&, bool, bool&) block_pointer) const + 179 10 dyld_sim 0x10d084b56 dyld3::MachOAnalyzer::forEachInitializerPointerSection(Diagnostics&, void (unsigned int, unsigned int, unsigned char const*, bool&) block_pointer) const + 118 11 dyld_sim 0x10d084d98 dyld3::MachOAnalyzer::forEachInitializer(Diagnostics&, dyld3::MachOAnalyzer::VMAddrConverter const&, void (unsigned int) block_pointer, void const*) const + 386 12 dyld_sim 0x10d06892a dyld4::Loader::findAndRunAllInitializers(dyld4::RuntimeState&) const + 144 13 dyld_sim 0x10d068ac2 dyld4::Loader::runInitializersBottomUp(dyld4::RuntimeState&, dyld3::Array<dyld4::Loader const*>&) const + 190 14 dyld_sim 0x10d068aa5 dyld4::Loader::runInitializersBottomUp(dyld4::RuntimeState&, dyld3::Array<dyld4::Loader const*>&) const + 161 15 dyld_sim 0x10d068aa5 dyld4::Loader::runInitializersBottomUp(dyld4::RuntimeState&, dyld3::Array<dyld4::Loader const*>&) const + 161 16 dyld_sim 0x10d068b60 dyld4::Loader::runInitializersBottomUpPlusUpwardLinks(dyld4::RuntimeState&) const + 102 17 dyld_sim 0x10d077b5a dyld4::APIs::runAllInitializersForMain() + 222 18 dyld_sim 0x10d05b9fe dyld4::prepare(dyld4::APIs&, dyld3::MachOAnalyzer const*) + 2528 19 dyld_sim 0x10d05be42 _dyld_sim_prepare + 379 20 dyld 0x110e6eb78 dyld4::prepareSim(dyld4::RuntimeState&, char const*) + 1265 21 dyld 0x110e6d70e dyld4::prepare(dyld4::APIs&, dyld3::MachOAnalyzer const*) + 244 22 dyld 0x110e6d4e4 start + 388 How can we overcome this issue? What Xcode is doing under the hood that xcodebuild doesnt do? Is it possible to release an SDK which import swiftUI but will have deployment target lower than 13. (I have wrapped all the the swift code with @available() and #if canImport(SwiftUI) - less relevant as its compile time )

Hi We had the following crash report from one of our customers that using our SDK: Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Subtype: KERN_INVALID_ADDRESS at 0x00009970accfd190 -> 0x00000070accfd190 (possible pointer authentication failure) Exception Codes: 0x0000000000000001, 0x00009970accfd190 VM Region Info: 0x70accfd190 is not in any region. Bytes after previous region: 2899300753 REGION TYPE START - END [ VSIZE] PRT/MAX SHRMOD REGION DETAIL commpage (reserved) 1000000000-7000000000 [384.0G] ---/--- SM=NUL ...(unallocated) ---> UNUSED SPACE AT END Termination Reason: SIGNAL 11 Segmentation fault: 11 Terminating Process: exc handler [8788] Triggered by Thread: 5 Any suggestion on the reason why it happens? I understand that msgSend is related to zombie but from the code I don't see where it might happen and it's only single client that has this issue. How to father investigate it crashlog.crash

class AppDelegate: NSObject, UIApplicationDelegate, UISplitViewControllerDelegate { var window: UIWindow? @objc func pendoEnterForeground() { print("pendoEnterForeground") } func applicationWillEnterForeground(_ application: UIApplication) { print("applicationWillEnterForeground") } func application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?) -> Bool { NotificationCenter.default.addObserver(self, selector: #selector(pendoEnterForeground), name: UIApplication.willEnterForegroundNotification, object: nil) ... Th following works correctly on app with scenes BUT on old apps without scenes the following doesn't work on App launch (on the following foreground background it does work)i.e:pendoEnterForeground and applicationWillEnterForeground doesn't get triggered on first app launch.

We are releasing IOS SDK and one of our customers has shared with us his crash log which is not symbolicated and shows a wrong instruction place in our SDK. We release our SDK with .DSYms stam2.txt I would like to symbolicate the Apple framework stack first so I have looked at the following : Code Type: ARM-64 (Native) OS Version: iOS 16.1.1 (20B101) I have downloaded the correct package for it: iOS DeviceSupport/16.1.1 (20B101) arm64 If I look at the binary images: 0x1cfeb9000 - 0x1d1696fff UIKitCore arm64-unknown <179501b60fc2344ab969b4e3961ebe10> /System/Library/PrivateFrameworks/UIKitCore.framework/UIKitCore so the uuid is 179501b60fc2344ab969b4e3961ebe10 BUT executing dwarfdump --uuid UIKitCore UUID: AA0A89BD-E48F-31DB-AD5C-5C724CE77D12 (arm64) UIKitCore in the iOS DeviceSupport/16.1.1 (20B101) arm64 gave me a different uuid I am wondering why the uuid are differnt? (I have also tried with arm64e) is there a way to symbolicated apple framework stack trace without the .DSYM file of the app? why the only symbolicated method is in our SDK (I guess it because we ship the SDK with .DSYM while the app developer didnt symbolize his crash logs)

One of our customers provided us with stack log crash . The crash is coming from within the SDK. It seems that the crash start to happen on iOS 15. (We were unable to reproduce it on the simulator and haven't tried it on device yet) We would like to have more insights about the crash and its reason as according to the reference refernce there is no Termination Reason or Code. CrashLogObfuscated.txt